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Abstract 

This paper introduces an extension of Medusa, a dis¬ 
tributed music environment, that allows an easy use of 
network music communication in common music ap¬ 
plications. Medusa was firstly developed as a Jack 
application and now it is being ported to other au¬ 
dio APIs as an attempt to make network music ex¬ 
perimentation more widely accessible. The APIs cho¬ 
sen were LADSPA, LV2 and Pure Data (external). 
This new project approach required a complete review 
of the original Medusa architecture, which consisted 
of a monolithic implementation. As a result of the 
new modular development, some possibilities of us¬ 
ing networked audio streaming via Medusa plugins in 
well-known audio processing environments will be pre¬ 
sented and commented on. 
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1 Introduction 

Ever since the availability of network and In¬ 
ternet connections became an undisputed fact, 
collaborative and cooperative music tools have 
been developed. The desire of using realtime au¬ 
dio streaming in live musical performances in¬ 
spired the creation of various tools focused on 
distributed performance, where synchronous mu¬ 
sic communication is a priority. Some related 
network music tools which address the prob¬ 
lem of synchronous music communication be¬ 
tween networked computers are NetJack [Carot 
et ah, 2009], Sound Jack [Carot et ah, 2006], 
JackTrip [Caceres and Chafe, 2009b; Caceres 
and Chafe, 2009a], llcon [Fischer, 2006] and 
LDAS [Saeb0 and Svensson, 2006]. 

The success cases of network music perfor¬ 
mance concerts could give the wrong impression 
that the only use for network music is distributed 


performance, but several other problems in com¬ 
puter music can take advantage of or benefit from 
network music distribution. For instance, record¬ 
ings can be made using a pool of networked com¬ 
puters, a resource which might be seen as a scal¬ 
able distributed sound card; music spatialization 
could be done using a mesh network topology; 
digital signal processing power can be vastly im¬ 
proved using clusters of computers; and musi¬ 
cal composition may explore fresh new grounds 
by viewing computer networks as nonstandard 
acoustical environments for performance and lis¬ 
tening. 

There are at least two requirements for all these 
scenarios to be fully explorable by potentially in¬ 
terested users, which are often musicians or afi¬ 
cionados and usually nonprogrammers; first, flex¬ 
ible audio network tools must be made available, 
and second, easy integration with popular mu- 
sic/sound processing applications must be guar¬ 
anteed. Despite the fact that most high-level 
linux music applications nowadays run over Jack 
and ALSA, we see that time and again end users 
can’t deal with this audio infrastructure lying 
below the application they are running. Also, 
the lack of automated setup and graphical user 
interfaces shun common users from many exist¬ 
ing tools, like the network music tools mentioned 
above. 

The work presented in this paper is part 
of the investigation behind the development of 
Medusa [Schiavoni et ah, 2011], a distributed au¬ 
dio environment. Medusa is a FLOSS project 
which is primarily focused on usability and trans¬ 
parency, as means to making network music con¬ 
nections easier for end users. The first implemen¬ 
tation of Medusa, presented in LAC 2011, was de¬ 
veloped in C++ with Qt GUI and Jack as sound 



API. The Jack API was extended with a series of 
network functionalities, such as add/remove re¬ 
mote ports and remote control of the Jack Trans¬ 
port functionality. 

Recently, the development of Medusa has been 
strongly guided by the attempt to deal with the 
two aforementioned requirements, namely flexibil¬ 
ity and integrability. These goals may be reached 
by extending regular sound processing applica¬ 
tions, such as Pure Data, Rosegarden or Ardour, 
allowing them to function as network music tools. 
The very basic idea is trying to reach end users 
wherever they already are. 

Most music applications can be extended by 
plugins: Pure Data can be extended by the cre¬ 
ation of C externals (which might be viewed as a 
plugin), whereas digital audio workspaces such as 
Ardour, Rosegarden, Qtractor and Traverso can 
be extended by LADSPA, VST and LV2 plugins. 
In this paper we will explore the possibility of 
developing Medusa network music plugins using 
three popular audio APIs: LADSPA, LV2 and 
Pure Data API (via C externals). It is worth 
mentioning that these APIs are all open-source, 
developed in C and widely used in Linux music 
environments. 

A reimplementation of Medusa has been re¬ 
quired in order to grant code reuse in the im¬ 
plementation of these plugins, and also for easy 
maintenance of the source code. All source code 
of the Medusa project, including Medusa plug¬ 
ins, are freely available in the project site 1 . This 
reimplementation of Medusa and the proposed ar¬ 
chitecture are presented in section 2; section 3 
discusses the chosen audio APIs and presents the 
developed plugins, and section 4 brings some con¬ 
clusions and a discussion of future works. 

2 Medusa 

Although some promising preliminary results 
had been achieved with the first version of 
Medusa [Schiavoni et ah, 2011], the original 
monolithic implementation raised several diffi¬ 
culties in the implementation of the proposed 
Medusa plugins, which eventually triggered a 
fundamental architectural change in the project. 
First, the implementation language was changed 
from C++ to ANSI C, which is more compatible 

1 http:/ / sourceforge.net / projects / medusa-audionet / 


with the chosen sound APIs. Second, the mono¬ 
lithic structure has been changed to the devel¬ 
opment of a core Medusa library (libmedusa.so), 
comprising control and network functions, which 
could be re-used by each new plugin implemen¬ 
tation. Third, graphical user interfaces, text- 
based interfaces and plugins now occupy a sep¬ 
arate layer, that uses the core Medusa library as 
an API on its own. 



Figure 1: Medusa Jack implementation with Qt 
GUI 

The new Medusa architecture is divided in 
three layers: Sound, Control and Network. The 
Control and Network layers are implemented as a 
unique library and are used by all Medusa imple¬ 
mentations. The Sound layer corresponds to spe¬ 
cific applications, like the proposed plugins, that 
are built using each plugin API and the Medusa 
library. This architecture facilitates code mainte¬ 
nance and bug correction. 



Figure 2: Architectural view of the implementa¬ 
tion 









































































2.1 Network layer 

The network layer is responsible for managing 
connections between network clients and servers. 
This layer’s implementation was made based on 
a fixed set of network transport protocols, which 
are normally provided as part of the operating 
system kernel, since its development and deploy¬ 
ment requires superuser privileges. Medusa cur¬ 
rently allows the user to choose among 4 transport 
protocols: UDP, TCP, SCTP e DCCP: 


senders and receivers and provides them to the 
Sound layer. Instead of requiring that all pro¬ 
tocols in the Network layer to have full-duplex 
communication, the Control layer always sepa¬ 
rates the roles of sending and receiving network 
data. 



Figure 3: Sender / Receiver communication 


UDP [Postel, 1980]: User Datagram Protocol is 
the classical unreliable (but faster) transport 
protocol. 

TCP [Padlipsky, 1982]: Transmission Control 
Protocol is a reliable transport protocol, 
which ensures absence of packet losses. 

SCTP [Ong and Yoakum, 2002]: Stream Con¬ 
trol Transmission Protocol is a connection- 
oriented transport protocol that provides a 
reliable full-duplex association. This proto¬ 
col was not originally meant as a replacement 
for TCP, but was developed for carrying voice 
over IP (VoIP). 

DCCP [Kohler et ah, 2006; Floyd et ah, 
2006]: Datagram Congestion Control Pro¬ 
tocol is a transport protocol that combines 
TCP-friendly congestion control with unre¬ 
liable datagram semantics for applications 
that transfer fairly large amounts of data [Lai 
and Kohler, 2005]. 

This multi-protocol network communication 
layer is intended to offer alternatives for users that 
may need different specific features in data trans¬ 
fer according to application context. For instance, 
an interactive musical performance with strong 
rhythmic interactions may require the smallest 
possible latency while tolerating audio glitches 
due to packet losses, and a remote recording ses¬ 
sion may tolerate high latency and jitter, but still 
require that every packet be delivered. With a few 
alternatives available, the user may choose which 
protocol is more appropriate to its own musical 
use. 

2.2 Control layer 

The next layer in the Medusa API is the Con¬ 
trol layer. The Control layer essentially creates 


In order to create a sender it is necessary to in¬ 
form the network protocol, the network port and 
the number of channels that will be sent. The 
sender creates the network server and one ring 
buffer for each channel, and provides functions 
for the sound API to have easy access to these 
buffers. Each ring buffer receives sound content 
from applications (usually in DSP chunks), out of 
which the sender prepares network chunks (usu¬ 
ally of a different size) for the Network Layer. 

The receiver is created in a way similar to the 
sender, but besides the basic parameters the cor¬ 
responding server IP address is also required. The 
receiver creates a network client and the required 
number of ring buffers (one per channel). Un¬ 
like the sender, the ring buffer of the receiver will 
be fed by a network client and consumed by the 
sound API. 

2.3 Sound layer 

The outermost Medusa layer is the Sound layer, 
which deals not only with audio streams but also 
with MIDI streams. The Sound layer lies be¬ 
tween the Medusa API and several sound applica¬ 
tion APIs, and represents a collection of Medusa 
front-ends or interfaces, since each integration of 
Medusa with a particular sound application may 
have its own user interface, defined by each sound 
application API. 

The integration of Sound and Network layers 
uses the Control layer through its sender / re¬ 
ceiver plugins. Sender and receiver roles defined 
by the Control layer are converted into Sound 
layer plugins that simply exchange audio streams 
between machines. 

Each plugin has a host application and a partic¬ 
ular way to communicate with it. The API defines 
how a plugin is initialized, how it processes data 
and how it is presented. Each plugin implemen- 







tation generates an independent software pack¬ 
age that can be individually used and distributed. 
The separation of these implementations avoids 
the mixing of different plugin libraries, which is 
better for code maintenance, chasing bugs and so 
on. 

3 Implementations 

3.1 LADSPA 

LADSPA [Furse, 2000] stands for “Linux Audio 
Developer Simple Plugin API”, and it is the most 
common audio plugin API for Linux applications. 
Many Linux programs, such as Audacity, Ardour, 
Rosegarden, QTractor and Jack Rack, support 
LADSPA plugins. The LADSPA API is captured 
within a header file and is very easy to use. Some 
examples are provided with an SDK and there is a 
lot of open source code with great documentation 
available. 



Figure 4: Medusa LADSPA implementation 

Figure 4 presents Medusa LADSPA sender and 
receiver interfaces. The controls of a LADSPA 
plugin are represented exclusively by 32 bit float¬ 
ing point numbers, and it was awkward to 
use these to represent IP addresses. LADSPA 
GUIs are defined in RDF files that cannot be 
changed on-the-fly, which makes them very cum¬ 
bersome as interfaces for network audio connec¬ 
tions. LADSPA doesn’t support MIDI and the 


documentation suggests the use of Rosegarden 
DSSI to deal with it. 

3.2 LV2 

LV2 (LADSPA version 2) [Steve Harris, 2008] is 
acknowledged as the official LADSPA successor. 
An LV2 plugin is a bundle that includes the plugin 
itself, an RDF descriptor in Turtle and any other 
resource needed. The LV2 bundle may include a 
GTK GUI, thus offering developers a way to cre¬ 
ate better user interfaces. As LADSPA, LV2 is an 
easy-to-use library, and plenty of documentation 
and examples are provided by the developers. 
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Figure 5: Medusa LV2 implementation 

The possibility of creating GTK interfaces al¬ 
lowed a more natural integration of Medusa as an 
LV2 plugin. The IP mask entry allows easy input 
for the user, and on-the-fly changes to the inter¬ 
face may be used by Medusa in the future to allow 
for finding users and sound resources and keeping 
this information up-to-date on the interface. 

3.3 Pure Data external 

Pure Data [Puckette, 1996] (aka Pd) is a largely 
used realtime programming environment for au¬ 
dio, video, and graphical processing, which can 
be extended by the use of externals written in 
C/C++ language [Zmolnig, 2001]. Pure Data 
does have some network externals available, but 
none offers all transport protocols provided by 
Medusa. A Pd external may also be implemented 
with a tcl/tk GUI, which can be useful to improve 
usability and also to implement Medusa service 
control in the future. In addition, Pd offers a good 
environment to measure latency, packet loss and 
jitter in Medusa Network layer implementation. 
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Figure 6: Medusa Pure Data external implemen¬ 
tation 

The Medusa Pd external implementation is ac¬ 
tually a collection of externals (a library) that 
includes the sender and receiver objects (see fig¬ 
ure 6) and a network meter to measure latency 
and packet loss. Some examples of use were also 
developed and are available on the project web¬ 
site. 

4 Conclusions and Future Works 

The possibility of exchanging sound data between 
applications using the Jack sound server, for in¬ 
stance, has brought new perspectives in audio 
software development and usage. Extending this 
possibility to allow for network data exchange 
from within popular user applications may fa¬ 
cilitate the emergence of new ways to compose, 
record or play music. It may be early to con¬ 
clude that network plugins for audio software will 
really expand the musical use of computer net¬ 
works, but it is not early to observe in users and 
musicians new expectations about what might be 
done in network music, and also the desire to try 
out new ways to do old things, maybe more easily 
and more transparently than before. 

The effort that went into changing Medusa ar¬ 
chitecture and reimplementeing it is totally justi¬ 
fied, in the sense that now the effort of implement¬ 
ing other network music plugins (i.e. Medusa plu¬ 
gins for other sound applications) involve a lot of 
code reuse and thus have been made much lighter. 

On the other hand, the first version of Medusa 
had an additional structure called Control Ser¬ 
vice, which was responsible for helping users to 
connect to network music resources in a transpar¬ 
ent way, in other words, without having to specify 
IP, network ports or audio configuration, using 
broadcast messages to publish networked audio 
resources. 
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start 


With that in mind, the level of usability orig¬ 
inally pretended by this project will only be 
reached when Medusa’s control service is imple¬ 
mented in the presented Medusa plugins, which is 
the very next step in our work. This control ser¬ 
vice is going to be responsible for improving trans¬ 
parency and usability, by including a discovery 
service, and a name server to publish networked 
music resources, thus allowing users to refer to 
other users and audio streams, instead of IP ad¬ 
dresses and network ports. Probably the Medusa 
LADSPA plugin will have to be abandoned at this 
point because the control service is impossible to 
implement without on-the-fly GUI modification 
(although the current version of the plugin, with¬ 
out control service, should be kept). 

Up to this point the plugin development has 
focused on audio streaming, but some other fea¬ 
tures must soon be addressed, such as treating 
MIDI streams and designing better GUIs. There 
are also other sound APIs that are been inves¬ 
tigated and maybe soon will be incorporated in 
Medusa Sound layer. 
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